home *** CD-ROM | disk | FTP | other *** search
/ Chip 2007 January, February, March & April / Chip-Cover-CD-2007-02.iso / Pakiet multimedia / Grafika i zdjecia / Edytory grafiki rastrowej i wektorowej / Inscape 0.44.1 / Inkscape-0.44.1-1.win32.exe / doc / README.document < prev    next >
Encoding:
Text File  |  2006-09-06  |  2.7 KB  |  78 lines
  1. 31.03.2000
  2.  
  3. Well, we end with 2 basic objects:
  4.  
  5. SPDocument - the base of all nongraphical wizardry.
  6. Although you can well do all things via repr tree, Document will have some
  7. neat features:
  8. Undo stack managing: start_undo_step, end_undo_step
  9. Selection grabbing - we can select via reprs, which is otherwise impossible
  10. NB! SPDocument is SPRepr ref holder NB!
  11.  
  12. SPDesktop - the base of all graphical wizardry
  13.  
  14. What follows, is outdated...
  15.  
  16. Document hierarchy
  17.  
  18. This is currently in active rewrite. Structure should be something like:
  19.  
  20. SPApp - main application thing, probably GnomeMDI in future
  21. SPDesktop - one view to one document
  22. SPDocument - SPItem tree rootmost element
  23.  
  24. SPItem tree refers to xml backbone (currently reprs) and Canvas trees.
  25. Backbone does not know anything about other items/classes/objects. There
  26. can be more than one canvas tree (desktop) associated with document.
  27.  
  28. There is (and should be more) event interconnection between different
  29. objects.
  30.  
  31. Editing can be done to all three levels, but should end up with modifying
  32. reprs. No other change will be saved.
  33. 1. Non-interactive modifications (for example changing object color)
  34. These should be done directly to backbone. Probably I'll implement a separate
  35. wrapper thing (sp-app-repr-interface.h or similar) to minimize the need
  36. to include lot of headers for such modules. These will be also probably the
  37. first interface to plugins.
  38. Such modifications will instantly propagate to all items and views and will
  39. be preserved when saving, duplicating & so on.
  40.  
  41. 2. Interactive modifications to SPItems
  42. These are a bit faster (no need of coding/decoding, allocing, freeing xml
  43. attributes). Changes will display instantly to all views, but WILL NOT
  44. propagate back to xml. The right way to use such things is:
  45. When button pressed, grab mouse pointer
  46. Do modifications to SPItem
  47. When button released, write modifications to SPRepr
  48.  
  49. 3. Interactive modifications to GnomeCanvasItems
  50. These affect only the current display (desktop) and DO NOT propagate back
  51. neither to SPItems, nor SPReprs. Use with same caution, as the class above.
  52.  
  53. Undo/Redo, when implemented, will be probably extracted from xml
  54.  
  55. There are several more things, like
  56. SPSelection - a per desktop selection (selection.h)
  57. Handful of canvas groups for grid, guidelines & so on (desktop.h)
  58. Intermediate holders of currently modified data (all contexts)
  59. SPNodepath (nodepath.h)
  60.  
  61. ---------------------
  62.  
  63. Document == SPRoot
  64. Provides convenience constructors
  65.  
  66. Selection { /* opaque */ }
  67. Per desktop structure, pointing to selected items
  68.  
  69. Desktop {
  70.     Selection selection
  71.     Document document
  72. }
  73.  
  74. macro ACTIVE_DESKTOP ;) gives current active desktop ;-)
  75. There will be probably several macros to deduce affected desktop from
  76. UI events (menus & so on)
  77.  
  78.